When Outbound and Finance Tax requirements impact master data records

Company Type: Large international FMCG company

Industry: Sales, Finance

Country: Spain, Portugal

Solution: SAP

Overview: Client’s current tax setup does not include Input tax that is applied when receiving financial documents from customers. Change in SAP (new tax) must be done in Outbound and Financial set-up which has direct impact on the material and customer master data. This missing set-up would cause inability to correctly perform settlement processes on client’s side with the SRM Solution that project was rolling-out.

Challenge: Volume of master data records and potential impact on sales and financial processes for markets that are outside of project’s scope (including one of the biggest markets for the client in North America). Addition of such tax line would make the data unusable as the blank entry for new tax would cause errors in SAP due to the fact that this is mandatory field and cannot be left without any value. Hence, fast update was required on all master data records for all impacted markets.

Benefits: Allows client to use the SRM Tool in full scope and improve the quality of data.

Time taken: Whole SRM tool implementation took just over 14 months, the detailed tax update took about 7 months (majority of the time was taken by client to assess change impact, agree on the solution and do regression testing).

Resources used by BPX: 2 Master Data consultants, 1 Outbound consultant, 1 Finance consultant

Process from Master Data side

1.Definition of impact

SAP Configuration changes done by Outbound area (change to pricing procedure, new entries in OVK1, OVK3, OVK4) caused new tax line to appear on materials and customers. To define the scope of the impact multiple tables and configuration set ups were checked:

• OMS2 – material set up // MLAN table entries
• KNVI table entries
• T001W entries (based on location of the plant)
• TVKWZ entries (impacted Sales Areas)

Based on those checks, three plants which were linked to three Sales Areas were identified as out of project scope (Middle East and North America regions).

Once all above was defined, export was made to check the volume of data that needs to be changed.

On customer side we defined around 20k records, on material side we defined around 110k records.

2.Update process

During the update process we faced one unexpected issue. Client currently is in gradual transition to MDG system. One of the sales areas impacted was currently in the testing phase for MDG-Material system. Our change had implication on their project as Outbound changes needed to be implemented in MDG as well. Based on that we defined the process into few areas and few steps:

• System:
  -MDG-Material
  -MDG-Customer
  -ECC/ERP
• Data Type:
  -Material
  -Customer
• Status:
  -Active
  -Partially activ
  -Blocked

Project was responsible for physical data population in ERP/ECC system and coordination of update in MDG systems. Priority was set to MDG-Material update, as the system was just introduced for the client and it still was not stable. Once that was signed off, update on MDG-Customer and ECC/ERP material was done in parallel.

On ERP/ECC side we had to respect the limitations that customer has in regard to amount of volume that is allowed to create as there are multiple systems linked with ERP/ECC and some systems cannot handle large volume of Idocs. Project was able to accommodate those restrictions by aligning with Service Team on Customer side which is responsible for monitoring the data flow between SAP and 3^rd party systems. It was possible to complete the update on ECC/ERP side within 3 days without overloading the system.On the side note – all active customer and materials were updated within first 24h once the outbound changes were productionized. The business for all the markets impacted has not reported any issues with the new tax line since productionizing.

Project team was able to complete the whole process using standard SAP tools with mass changes and schedule the updates in advance to use the time efficiently, but still not overload the system for other users. The success of the update process was also possible thanks to very detailed analysis and few tests done in test system that proved the concept and made the client secure in the actions.